3章 事業活動の複雑さに立ち向かう
システム設計の本質は境界の決定
システム設計は文脈の設計
境界の内側に何があり、境界の外側に何があるのか。境界を超えて、どうつながり、何が移動するのか。何を選択し、何を諦めるか。境界は、何が外部で何が内部であるかを明確にする。
異なるモデルの混在
同じ言葉(ユビキタス言語)をでも、文脈によって異なる意味を指すケースが有る ex: 事業活動がテレマーケティングの場合
見込み客をユビキタス言語として扱う
販売促進部門
「見込み客」は自社製品に興味を持った人の連絡先を指している
営業部門
「見込み客」は営業ライフサイクル全体を表現している
「販売促進の見込み客」や「営業の見込み客」のように文脈を名前に付ける方法もあるが以下の観点で好まれない
一つの言葉を異なる意味で使い分けるのは認知負荷の増加につながる
2つのモデルが混在したソースコードはユビキタス言語の考え方に反する
一つの言葉が複数の意味で使われる場合、同じ言葉を複数の小さな同じ分割し、それを適応できる明確な文脈である区切られた文脈に割り当てる 事業活動がそれなりの規模になれば、言葉の意味が衝突し文脈が暗黙化する。区切られた文脈は暗黙の文脈を明確にするための方法
個々の課題領域に特化して表現したモデルを作るための手法
事業全体をいくつかのモデルに分割し、それぞれのモデルが適応する範囲を厳密に定義する
文脈の境界
モデルを作るためには、適切な境界が必要
モデルは複雑な現実を理解するための抽象概念。モデルで重要なのは目的で解決対象の課題を明確にする
区切られた文脈は、独立したサービス、プロジェクトとして開発し、物理的に切り離すのが好ましい(マイクロサービス) 文脈の大小
区切られた文脈の大きさは、取り組んでいる課題に依存する
大きくしすぎた場合
モデルと用語の一貫性が失われてしまう
小さくしすぎた場合
それらを組み合わせて全体を組み立てるのがやっかいになる
takumines.icon適切な大きさの判断は、ブラッシュアップしていくことで得られると思う
大きく区切った文脈を、小さな文脈に区切るメリット
開発チームを増やす場合
個々が異なる文脈範囲の開発をできるため、コンフリクトが発生しにくい
注意点
一つの変更要求に対応するために、複数の区切られた文脈を同時に修正する必要がある状態は文脈の単位が誤っているため、見直しが必要
業務領域と区切られた文脈の関係
事業活動の分析によって中核・補完・一般に業務領域を分類し、競合他社との差別化を明確にする
事業領域は事業方針から決まる
区切られた文脈は「設計」
モデルの領域を設計し、どのように事業活動を小さく扱いやすい境界に分類するかを決定する
区切られた文脈はエンジニアが決める